На прошедшей конференции VMware VMworld 2013 в Барселоне компания VMware объявила о скорой доступности решения для виртуализации настольных ПК предприятия VMware Horizon View 5.3 (напомним, что о возможностях версии 5.2 мы писали тут). Несмотря на то, что новая версия продукта продвинется всего лишь на 0.1 единицу, в ней будет очень много новых возможностей, главная из которых - полноценная поддержка 3D в виртуальных ПК.
vGate Compliance Checker позволяет проверить инфраструктуру VMware vSphere 5.1/5.0/4.1 на предмет соответствия следующим стандартам и лучшим практикам:
Результатом проверки, которую специалисты смогут провести с помощью vGate Compliance Checker, станет структурированный отчет (возможно экспортировать в HTML), представляющий информацию о положениях стандартов и о соответствии протестированной системы этим положениям. Проверять систему можно выборочно на соответствие только интересующим стандартам и лучшим практикам.
Средняя скорость проверки соответствия систем, в которых присутствует до 3 серверов виртуализации, занимает около 1 минуты.
Скачать vGate Compliance Checker можно по этой ссылке.
Мы уже писали о технологии VMware VSAN, которая позволяет построить распределенный кластер хранилищ на базе локальных дисков серверов VMware ESXi. Этот кластер позволяет отказоустойчиво хранить виртуальные машины и обращаться к ним с любого из хостов. Недавно компания VMware опубликовала результаты тестов работы ВМ в VDI-инфраструктуре на базе хранилищ VSAN.
Не так давно компания Veeam Software объявила о скором выпуске новой версии пакета Management Pack for VMware v6.5, который может быть использован совместно со средством мониторинга инфраструктуры Microsoft System Center Operations Manager (SCOM).
Напомним, что Veeam Management Pack for VMware позволяет осуществлять комплексный мониторинг виртуальной инфраструктуры VMware vSphere посредством SCOM в рамках единого подхода к мониторингу и решению проблем в ИТ-инфраструктуре предприятия (как физической, так и виртуальной). Напомним, что о прошлой версии Veeam Management Pack for VMware 6.0, которая вышла в апреле этого года, мы уже писали вот тут.
Итак, новые возможности Veeam Management Pack for VMware 6.5:
New enhanced fault tolerance - возможность автоматического перенаправления сбора данных с сервера vCenter на хосты ESXi, если первый по каким-то причинам оказался недоступен. То есть если vCenter упал, сбор данных идет напрямую с ESXi, если поднялся - автоматически восстанавливается сбор данных с vCenter, без прерывания процесса мониторинга.
New configuration tracking and alert correlation - теперь Veeam MP отслеживает все происходящие в виртуальной инфраструктуре vSphere изменения и позволяет отследить на какие ее аспекты эти изменения повлияли.
New monitoring and reporting for Veeam Backup & Replication - теперь появилась возможность мониторинга не только платформы VMware vSphere, но и инфраструктуры резервного копирования Veeam Backup and Replication, включая его прокси-серверы, серверы с репозиториями, WAN-акселераторы, непосредственно сами задания резервного копирования и многое другое.
New platforms support - теперь Veeam Management Pack for VMware 6.5 поддерживает ОС Windows Server 2012 R2 + System Center 2012 R2 Operations Manager, vCenter Server 4.x и более поздних версий, а также ESX 4.x и более поздние. Само собой, новая версия MP от Veeam поддерживает VMware vSphere 5.5.
Мы традиционно извещаем читателей о том, что компания VMware выпускает черновые и релизные версии своих
руководств по обеспечению безопасности виртуальной среды VMware vSphere (последние тут и тут). На этот раз
руководство вышло заметно быстрее - всего пару месяцев спустя после анонса vSphere 5.5 появилась и бета документа
VMware vSphere 5.5 Hardening Guide.
Как обычно руководство представлено одним Excel-файлом и разделено на следующие секции:
Virtual Machines
ESXi hosts
Virtual Network
vCenter Server (а также различные БД и клиенты)
vCenter Web Client
vCenter SSO Server
vCenter Virtual Appliance (VCSA) и различные аспекты его использования
Не так давно мы писали о технологии VMware
VSAN, которая позволяет строить распределенные кластеры хранилищ на базе локальных дисков серверов VMware ESXi
и которая была анонсирована на прошедшей конференции VMworld 2013. Напомним, что эта технология была куплена
вместе с компанией Virsto Software (у нее русские корни, между прочим), и она на данный момент находится в статусе бета-версии. Эта штука умеет использовать
локальные диски как источник хранения данных, а SSD-накопители - как кэш на чтение и буфер на запись.
На днях компания VMware выпустила интересный документ для тех, кто хочет немного вникнуть в архитектуру решения
VMware VSAN - "What’s New
in VMware Virtual SAN (VSAN)".
Документ содержит следующие секции:
Introduction
Requirements
Install and Configure
Architecture Details
Storage Policy Based Management
Пример создания кластера VSAN представлен ниже - видно, что он поддерживает все распределенные службы VMware -
HA, DRS, vMotion и прочее.
Создаваемые VSAN-хранилища управляются на базе политик, которые определяются правилами, например, избыточность
в хостах или число дисковых страйпов:
Эти политики хранилищ можно назначать виртуальным машинам при создании, а также проверять различные сущности
VMware vSphere на соответствие им. В общем, интересный документ - почитайте.
Как многие знают, еще в прошлых версиях VMware vSphere появилась такая возможность, как задание нескольких виртуальных ядер для vCPU виртуальных машин (cores per socket), которое требуется, в основном, для случаев хитростей с лицензированием. То есть, например, для случаев, когда требуется покрыть лицензиями только виртуальные сокеты, а производительности нужно больше (как вариант - так можно поступать с лицензиями Windows Server не Datacenter Edition).
Многих также заботит вопрос, повлияют ли изменения, сделанные тут, на производительность ВМ. Ответ прост - возможно, если вы изменяете дефолтную конфигурацию и ставите больше одного виртуального ядра на виртуальный процессор. Поэтому без лицензионной надобности лучше эти настройки не менять.
Оставлять по одному ядру на виртуальный процессор машин.
Если все-таки приходится изменять число ядер на vCPU, то нужно знать особенности организации архитектуры сервера.
Про второй пункт и идет речь ниже. Дело в том, что в VMware vSphere есть такая технология как vNUMA, которая работает при количестве vCPU равном 8 и больше для одной виртуальной машины и позволяет самым оптимальным образом отображать физическую архитектуру сервера на топологию NUMA-узлов виртуальной машины (по количеству и размеру).
Например, для процессора AMD Opteron 6174, который имеет два 6-ядерных процессора, объединенных в единый сокет - такая архитектура представляет собой 8 NUMA-узлов (две пары на один процессор). Таким образом для конфигурации без изменения cores per cpu для виртуальной машины технологией vNUMA будет поддерживаться 8 vNUMA узлов, что отлично отражает физическую архитектуру:
Это для случая, когда мы не изменяем количество ядер на vCPU. В VMware прогнали тест в гостевой ОС (какая-то внутренняя утилита) и получили базовое время исполнения этого бенчмарка для указанной конфигурации:
Если же в ВМ ядер на виртуальный сокет больше одного, то размер vNUMA будет равен количеству процессоров ВМ. Выставляем 2 сокета с 12 ядрами на сокет:
Получаем 2 vNUMA-узла, что не совпадает с конфигурацией оборудования:
Поэтому тест выполняется подольше:
А вот если сделаем целых 24 ядра на один сокет:
То получим всего один узел vNUMA:
И как следствие, самую низкую производительность ВМ:
65 секунд против 45 в первом тесте, что означает падение производительности на 31% для данного случая. Поэтому не меняйте просто так число ядер на процессор. Само же количество процессоров можно менять смело.
Дополнительную информацию по этому вопросу можно найти тут:
На днях компания Citrix выпустила техническое превью решения для виртуализации настольных ПК предприятия Citrix XenDesktop 7.1.
Основная цель релиза XenDesktop 7.1, уже доступного для загрузки - поддержать новые версии операционных систем Microsoft Windows 8.1 и Windows Server 2012 R2, которые уже скоро станут доступными (по традиции - в октябре), а корпоративные заказчики уже сейчас хотят попробовать их в VDI-среде.
Если говорить конкретнее, то XenDesktop 7.1 позволит попробовать следующие новые возможности этих ОС:
Использовать гипервизор Hyper-V 3 с поддержкой локальных хранилищ для служб Machine Creation Services (MCS).
Перенаправление Flash-графики для ОС Windows 8.1, Windows 8, Windows Server 2012 R2 и 2012 (непонятно, правда, зачем оно нужно серверным системам).
Данный релиз XenDesktop 7.1 может использовать Windows 8.1 в качестве гостевой ОС для виртуальных ПК и ОС Windows Server 2012 R2 для развертывания управляющих компонентов решения. Доступен он только для пользователей XenDesktop с активной подпиской (Subscription Advantage).
Кроме того, была анонсирована поддержка платформой Citrix XenServer технологии NVIDIA GRID, о которой мы уже не раз писали (например, тут и тут). Официальный релиз поддержки технологии как раз совпал с выпуском превью XenDesktop 7.1, являющегося основой VDI-решений с поддержкой технологии NVIDIA (vGPU). Для XenDesktop 7.0 такой поддержки нет и, по всей видимости, не будет.
С использованием технологии XenServer hardware GPU sharing (поддерживается в XenServer 6.2) становится доступным применение виртуальных графических адаптеров (vGPU) в виртуальных машинах, напрямую использующих ресурсы специального аппаратного обеспечения от NVIDIA и осуществляющих интенсивную обработку 3D-графики. На абы-каком оборудовании использовать эту технологию не получится, поэтому предварительно советуем прочитать вот эту статью от Citrix.
Технология NVIDIA GRID доступна как для Citrix XenServer, так и для VMware vSphere / ESXi (основа VDI-решения VMware View), однако Citrix заявляет, что использует нативные драйверы NVIDIA, в то время как VMware - свои собственные (режимы vSGA и vDGA - подробнее об этом тут):
Ограниченная функциональность режимов vSGA и vDGA у VMware vSphere заключается в следующем:
В общем-то логично, что NVIDIA тут делает ставку на лидера рынка виртуальных ПК - Citrix, однако мы ожидаем и полноценной поддержки VMware vSphere / View уже в ближайшем будущем.
Надо отметить, что технология vGPU от Citrix пока работает для гостевых ОС Windows 7 и Windows Server 2008 R2, поэтому с новой Windows 8.1 попробовать ее пока не получится. Ну и добавим также, что для Hyper-V на данный момент нет аналогов механизмам виртуализации и проброса GPU в виртуальные машины.
Многие администраторы виртуальной инфраструктуры VMware vSphere сталкиваются с необходимостью копировать файлы в гостевую ОС виртуальных машин. Делают они это путем копирования на системную шару или обычный общий ресурс, пробросом дисков через RDP и прочими методами.
Но многое из этого оказывается неприемлемым по тем или иным причинам. Чтобы этого всего избежать, Manfred Meier выложил на сайте VMware Directory утилиту vGuestExplorer, которая позволяет получить доступ к файловой системы гостевой ОС виртуальной машины даже без непосредственного сетевого соединения с ней.
Делается это посредством соединения по PowerCLI / PowerShell через VIX API к гостевой ОС виртуальной машины. Можно подключаться к серверу VMware vCenter, а можно к отдельному хосту VMware ESXi. Обязательно наличие установленных VMware Tools в гостевой ОС.
Работает vGuestExplorer как для Windows, так и для Linux.
Установка утилиты проста:
Устанавливаем PowerCLI и выставляем параметр Set-Executionpolicy как Unrestricted.
Выполняем PowerCLI как Administrator и запускаем команду: Set-PowerCLIConfiguration -InvalidCertificateAction ignore -ProxyPolicy NoProxy -Confirm:$False
Запускаем установку vGuestExplorer.
Убедитесь, что VMware Tools установлено в той ВМ, в которую вы будете копировать файлы.
Многие пользователи VMware vSphere применяют репликацию уровня хоста (host-based) для защиты виртуальных машин и их хранилищ. Сама эта технология появилась еще в версии VMware vSphere 5.1 и активно используется в vSphere 5.5. Напомним также, что функции vSphere Replication используются в решении VMware Site Recovery Manager для построения катастрофоустойчивой инфраструктуры небольших компаний.
На днях компания VMware выпустила виртуальный модуль (Virtual Appliance) под названием vSphere Replication Capacity Planning Appliance, который призван помочь при планировании пропускной способности канала сети под репликацию.
Эта бесплатная утилита, доступная на сайте проекта VMware Labs, позволяет смоделировать воздействие vSphere Replication на продуктивную сеть без реальной генерации трафика.
Возможности vSphere Replication Capacity Planning Appliance:
Интерфейс командной строки для настройки репликации в режиме "preview mode", без реального потребления хранилища.
Веб-страница, представляющая графики по потреблению канала для каждой репликации.
Не требует ресурсов сети и хранилищ.
Как начать пользоваться:
Установить виртуальный модуль.
Как только он загрузится, залогиниться по SSH или в консоль с логином/паролем - root/vmware.
Выполнить команду:
cd /opt/vmware/hbrtraffic/
Выполнить команду для симуляции репликации конкретной ВМ (VM_name): ./bin/configureReplication --vc --vcuser Administrator --vcpass --lwd <IP_of_the_Appliance> --vmname <VM_name>
После того, как операция будет выполнена (10-15 минут) получившиеся графики можно посмотреть по адресу:
https://IP_of_the_Appliance:5480/vr-graphs/
Скачать vSphere Replication Capacity Planning Appliance можно по этой ссылке.
Мы уже не раз писали (тут и тут) про расширенные настройки (Advanced Settings) кластеров VMware HA в VMware vSphere (до версии 5.0 включительно). Эти настройки позволяют гибко настраивать различные параметры кластеров, их поведение, определять сетевые настройки и т.п. В этой статье мы приведем все эти настройки в единую таблицу и актуализуем для версии VMware vSphere 5.5.
Таги: VMware, vSphere, HA, vCenter, FDM, ESXi, VMachines
Как многие помнят, у компании VMware был TCO-калькулятор (который она делала совместно с компанией Alinean), позволявший посчитать совокупную стоимость владения виртуальной инфраструктурой (Total Cost of Ownership, TCO) как для серверной инфраструктуры VMware vSphere, так и для VDI-среды VMware View.
Теперь на его базе компания VMware создала утилиту VMware Cloud Compass Tool (также совместно с Alinean), которая рассчитывает не только показатели TCO, но и умеет определять необходимый пользователю тип облака: приватное, публичное или гибридное:
VMware Cloud Compass предназначен для следующих целей:
Расчет и сравнение моделей TCO (с учетом CapEx и OpEx) для различных вариантов платформ и параметров для онпремизной инсталляции, а также для различных типов облаков.
Оценка устойчивости инфраструктуры к различным рискам, включая такие параметры как доступность, соответствие требованиям отраслевых стандартов, безопасность и т.п.
Оценка необходимых параметров публичного или приватного облака для построения облачного решения в своей организации, а также оценка затрат на эту активность.
Результаты расчетов VMware Cloud Compass доступны онлайн, но при желании их можно скачать в формате PDF и обсудить с коллегами и руководством.
Сразу после релиза обновленной версии платформы vSphere
5.5 компания VMware выпустила очень интересный и полезный документ Performance Best Practices for VMware vSphere 5.5, в котором
рассматриваются аспекты производительности серверов VMware ESXi и виртуальных машин уже с учетом функциональности новой версии.
Например, теперь в документе описаны следующие фичи в контексте производительности:
Функции кэширования на SSD-накопителях vSphere Flash Read Cache, о которых мы писали вот тут. Они увеличивают производительность за счет применения кэша на чтение для операций ввода-вывода виртуальных
машин.
Возможность VMware Virtual SAN (VSAN), о которой мы писали тут.
Она позволяет использовать локальные ресурсы хостов ESXi для построения распределенной инфраструктуры хранения виртуальных машин.
База данных VMware vFabric Postgres database (vPostgres).
Кроме того, были обновлены и дополнены следующие темы в документе (который уже можно смело называть книгой, так как занимает он 90 страниц):
Использование нагрузок в ВМ, чувствительных к скорости подсистемы ввода-вывода и сетевому взаимодействию (интересна также статья в тему)
Техники NUMA и Virtual NUMA (vNUMA)
Техники экономии памяти хоста (Memory overcommit)
Технология Large memory pages
Техника Receive-side scaling (RSS), как в гостевых ОС, так и для адаптеров 10 Gigabit Ethernet
Средства миграции VMware vMotion, Storage vMotion, а также Cross-host Storage vMotion
Техники балансировки нагрузки VMware Distributed Resource Scheduler (DRS) и экономии электропитания Distributed Power Management (DPM)
Обновленный (а точнее полностью переписанный) VMware Single Sign-On Server (об этом у нас тут)
В новой версии VMware vSphere 5.5 при развертывании сервера vCenter 5.5 появился выбор между Simple и Custom методами установки:
Когда вы развертываете VMware vSphere 5.5 в небольшой организации (или делаете апгрейд с vSphere 5.1), где есть несколько серверов ESXi - однозначно следует выбирать Simple Install для сервера vCenter. Это установит все управляющие компоненты на один сервер в следующей последовательности:
Custom Install для vCenter нужно использовать только в следующих случаях:
Установка нескольких серверов vCenter в режиме Linked Mode (при этом первый сервер развертываем в Simple Install, а остальные - в режиме Custom). Помните, что серверы vCenter 5.1 не поддерживаются для Linked Mode в vCenter 5.5.
Разнесение управляющих компонентов по разным виртуальным или физическим серверам (актуально для очень крупных инфраструктур).
Выбор собственной директории для vCenter вместо стандартной C:\Program Files\VMware\Infrastructure
В остальных случаях будет вполне достаточно режима Simple Install для vCenter 5.5.
Кстати, интересен пост о том, что VMware постепенно укорачивает цикл релизов платформы VMware vSphere. Вот как изменяется число дней от одной мажорной версии до другой:
Напомню, что нет смысла сразу бросаться и устанавливать VMware vSphere 5.5 на свои серверы. Как многие помнят, у VMware с выходом новой версии часто появляются баги (например, тут и тут), иногда весьма критические (многие помнят баг с тайм-бомбой), поэтому лучше немного подождать и почитать блоги и новостные ресурсы (например, наш), где будут появляться записи о серьезных ошибках, если таковые там имеются.
Вместе с релизом VMware vSphere 5.5 компания VMware также выпустила симулятор сервера управления - vCenter Server Simulator 2.0 (VCSIM 2.0). Напомним, что это средство (о котором мы писали вот тут) позволяет эмулировать сервер VMware vCenter в котором запущены тысячи виртуальных машин, при этом такие объекты потребляют минимум ресурсов и работают на минимальной конфигурации VMware vCSA (vCenter Server Appliance).
А еще это хорошо подходит для всякого рода демонстраций (потемкинские инфраструктуры) и тестов:
Утилита VCSIM 2.0 входит в состав виртуального модуля vCSA 5.5 (vCenter Server Appliance), но отсутствует в обычной инсталляции vCenter.
Что нового появилось в VCSIM 2.0:
Поддержка Virtual Switch (VDS):
Добавление и удаление хостов ESXi из VDS
Создание/удаление Distributed Virtual Portgroup
Настройка Distributed Virtual Portgroup
Добавление/удаление виртуальной машины из Distributed Portgroup
Поддержка vCloud Networking & Security (vCNS) Support:
Развертывание/удаление объектов vApp с включенным сервисом DHCP
Сохранение постоянной конфигурации окружения при перезагрузке:
Folder
Cluster
Resource Pool
Host
Datastore
Virtual Machine
Network
VDS
Поддержка настройки компонентов:
Шаблон ESXi version
Шаблон ESXi configuration
Настройка хранилищ (Datastore)
Настройка Virtual Machine datastore
Простые команды управления симулятором:
vmware-vcsim-start
vmware-vcsim-stop
Перед использованием VCSIM нужно сначала ознакомиться с инструкциями, приведенными вот в этой статье. Более подробнее о новых возможностях VCSIM 2.0 можно почитать вот тут.
Как мы уже недавно писали, одной из новых возможностей VMware vSphere 5.5 стали функции расширенного управления электропитанием серверов vSphere Host Power Management (HPM). Ранее о таких функциях на платформе VMware vSphere мы рассказыали вот тут.
HPM - это совокупность техник, позволяющих оптимизировать потребление электроэнергии хостом VMware ESXi, когда он находится в состоянии простоя или пониженной нагрузки.
Управление электропитанием происходит через интерфейс Advanced Configuration and Power Interface (ACPI), который позволяет управлять состояниями P-states и C-states. В VMware vSphere 5.0/5.1 дефолтная политика управления питанием была основана на технологии dynamic voltage and frequency scaling (DVFS).
Эта технология использует P-states процессора, что позволяет экономить некоторое количество энергии за счет поддержки процессора на более низкой частоте и напряжении. Но, начиная с VMware vSphere 5.5, политика HPM использует расширенный набор состояний halt states (они же C-states) в дополнение к DVFS. Это намного больше увеличивает экономию энергии при сохранении хорошей производительности, так как состояния C-states процессора почти не сказываются на его производительности, а питания потребляют значительно меньше (а иногда производительность даже растет, особенно для легких и средних нагрузок без большого потока операций ввода-вывода).
Так как теперь ESXi использует весь спектр возможностей по управлению питанием хоста, то в BIOS большинства серверов нужно предоставить гипервизору полномочия на действия по оптимизации энергопотребления процессора. По умолчанию на большинстве серверов такие функции выключены.
Для того чтобы их включить, например, в серверах HP нужно в BIOS зайти в Power Management Options -> HP Power Profile и выбрать пункт Custom. Затем нужно зайти в Power Management Options->HP Power Regulator, где выбрать пункт OS Control Mode.
Для управления глубокими режимами C-states (C1/C1E, C3 и C6) нужно также разрешить их использование со стороны программного обеспечения в BIOS сервера:
Для VMware HPM есть 4 различных политики электропитания:
High Performance - в этом состоянии процессор находится в самом высоком P-state все время, а для C-states используется всего 2 режима: running и halted. Это дефолтная политика для vSphere 5.0 и более ранних версий.
Balanced - вот эта политика и позволяет использовать как P-states для экономии питания, так и, начиная с vSphere 5.5, C-states, выбор которых производится на основе оценки со стороны ESXi с использованием статистического прогноза на время простоя процессора.
Low Power - в этом режиме хост делает все, чтобы снизить потребление энергии, используя алгоритмы P-states и C-states состояний.
Custom - по умолчанию эта политика выставлена как Balanced, но ее уже можно крутить для получения нужного результата.
Для политики Custom есть несколько интересных параметров, которые можно покрутить, если очень хочется (их число по сравнению с прошлой версией ESXi возросло):
По результатам тестов использование C-states для режима Turbo mode дает существенный прирост производительности (при том, что само по себе включение турбо-режима прироста почти не дает):
А вот как использование deep C-states позитивно влияет на потребление электроэнергии:
Интересный график экономии питания в зависимости от нагрузки хост-сервера - получается, что максимальная эффективность у HPM - до 30% загрузки CPU:
Очень часто при чтении документации VMware приходиться сталкиваться с различного рода сокращениями, большинство из которых, конечно же, понятно опытным администраторам VMware vSphere, но не всегда понятно для новичков.
Andrea Mauro составил неплохой список акронимов VMware, который мы и публикуем здесь (ссылки добавил я - на релевантные статьи):
AAM
Automated Availability Manager (aka VMware HA since v 4.1)
Среди анонсов VMworld 2013, о которых мы писали вот тут, помимо обновленной платформы виртуализации VMware vSphere 5.5, было также объявлено о выпуске средства единой аутентификации в виртуальной инфраструктуре - VMware vCenter Single Sign-On 5.5 (SSO).
На самом деле это всего лишь версия 2.0 компонента SSO, но она уже была полностью переписана по сравнению с первой версией, у которой наблюдались серьезные проблемы, а именно:
Ограниченная интеграция с Active Directory
Сложность управления инфраструктурой SSL-сертификатов
Отсутствие четких инструкций и рекомендаций по развертыванию продукта
Сложность развертывания решения, особенно для администраторов небольшой инфраструктуры
Надо отметить, что SSO версии 1.0 компания VMware оеэмила у сторонних разработчиков, но ввиду его неудобства решила написать его для себя с нуля.
Теперь Single Sign-On 5.5 лишен перечисленных проблем, архитектурно он стал проще - нет нужды в сторонней базе данных, все построено на базе внутренней модели хранения LDAP. Мастер установки стал очень простым и позволяет без труда развернуть SSO не несколько узлов vCenter 5.5:
Теперь архитектура построена на модели multi-master, что предполагает наличие идентичной конфигурации на каждом узле, между которыми происходит встроенная в решение репликация. Теперь можно создавать логические группировки зарегистрированных ресурсов, например, по географическому признаку.
Обновилась и утилита vCenter Certificate Automation tool, которая теперь позволяет простым образом обновлять сертификаты компонентов средств управления виртуальной инфраструктурой vCenter Server 5.5.
Помимо прочего, теперь нет и заморочек с master password, которые вводили в недоумение многих пользователей.
VMware рекомендует устанавливать SSO вместе с сервером vCenter, а один экземпляр SSO может работать в инфраструктуре до 1000 хостов ESXi и 10 000 виртуальных машин.
Из остальных функций Single Sign-On 5.5 можно отметить следующие:
Поддержка односторонних и двусторонних AD-трастов
Поддержка нескольких лесов
Можно использовать локальную аутентификацию без домена, если это необходимо
Появилось множество средств для траблшутинга и диагностики решения
VMware vCenter Single Sign-On 5.5 можно будет скачать в составе инфраструктуры VMware vSphere.
Некоторое время назад мы писали про технологию Virtual SAN (VSAN) компании VMware, которая позволяет объединить локальные дисковые ресурсы хост-серверов VMware ESXi в единый пул хранения для виртуальных машин, управляемый на базе политик. Этот продукт сейчас находится в стадии публичного бета-тестирования, и основан он на разработках купленной компании Virsto.
Однако многие из вас знают, что у VMware есть также продукт vSphere Storage Appliance (VSA), о котором мы также немало рассказывали на страницах VM Guru (например, тут, тут и тут). И этот продукт также предназначен для построения распределенных хранилищ на базе локальных дисков хостов, но уже для небольшой инфраструктуры.
Давайте посмотрим, чем же отличаются эти два продукта - VMware VSA и VMware VSAN:
Категория
vSphere Storage Appliance
(VSA)
VMware Virtual SAN (VSAN)
Описание
Дешевое общее хранилище для компаний или филиалов, не имеющих возможности купить дисковые массивы для площадок.
Масштабируемое распределенное хранилище для развертывания в облачной инфраструктуре.
Способ поставки
Виртуальный модуль (Virtual Appliance)
Работа механизма встроена в ядро vSphere
Целевые рынки
Средний и малый бизнес
Установка в филиалах (ROBO)
Enterprise-инфраструктура
Коммерческие компании
Масштабируемость
2-3 сервера VMware vSphere
Не масштабируется больше 3-х хостов
Развертывание минимум на 3 хоста
Масштабирование до полного кластера vSphere
Производительность
Без поддержки SSD (низкая производительность)
Технология SSD caching (высокая производительность)
Функциональность
Простая установка и настройка
Масштабируется до 16 ТБ используемого хранилища
Интегрировано с vCenter
Техники SSD caching и intelligent data placement
Быстрое развертывание хранилищ
Масштабируемость для больших установок
Гранулярность при масштабировании хранилищ
Управление хранилищами на базе политик
Из таблички видно, что продукт vSphere Storage Appliance подходит для небольших компаний и начинающих в сфере виртуализации, а вот технология VSAN подойдет уже серьезным организациям с большой продакшен-инфраструктурой.
На самом деле, так как продукты делали разные компании (VSA - VMware, а VSAN - Virsto), то они имеют разные функции и не являются вариациями одного и того же решения, хотя многие понимают VSAN как развитие идеи VSA.
Продолжаем вас знакомить с продуктом vGate R2, предназначенным для защиты виртуальных сред VMware vSphere. 18 июля 2013 г. компания «Сертифицированные информационные системы» объявила о получении сертификата ФСТЭК России на VMware vSphere 5.1 и программное обеспечение для виртуализации рабочих мест VMware View 5.1... Таги: Security Code, Security, vGate, Сравнение, VMware, vSphere
Некоторое время назад мы уже выкладывали интерактивные демо продуктов VMware, но с тех пор уже много воды утекло, и демки устарели. На прошедшей конференции VMworld 2013 компания VMware анонсировала новые версии своих продуктов, например, VMware vSphere 5.5 и vCloud Director 5.5, а к ним она приложила интерактивные демо, воспользоваться которыми в целях обучения может любой желающий.
На прошедшей конференции VMworld 2013 компания VMware представила свое виденье концепции ЦОД будущего - Software-Defined Datacenter, то есть датацентр, определяемый и направляемый программно, в котором слой оборудования полностью отделен от слоя программного обеспечения, а последний и реализует все необходимые сервисы пользователей и функции управления. То есть, оборудование - это просто подложка, элементы которой можно будет заменять, а все необходимые функции управления будут находиться на стороне программного обеспечения.
Выглядит это так:
В рамках этой концепции было объявлено о работе VMware в четырех направлениях:
Расширение применения технологии виртуализации на все приложения (например, кластеры Hadoop).
Трансформация хранилищ в абстрагированные и агрегированные дисковые ресурсы серверов (Virtual SAN) на базе разработок компании Virsto (с русскими корнями, кстати).
Создание программно-определяемых сетей в датацентре на базе продукта VMware NSX, полученного после покупке компании Nicira.
Сегодня мы поговорим о третьем пункте - решении для построения виртуальной инфраструктуры сетей - VMware NSX, которое было анонсировано на VMworld как один из ключевых компонентов стратегии VMware в рамках концепции Software-defined networking (SDN).
VMware NSX - это решение полученное на основе двух продуктов: купленного Nicira NVP и собственного VMware vCloud Networking and Security (vCNS). Последний предназначен для комплексной защиты виртуального датацентра и построен на базе семейства продуктов VMware vShield. Решение VMware NSX предназначено для крупных компаний, которые планируют повысить степень гибкости сетевой среды датацентра, который связан с другими ЦОД компании, и где требуется переносить виртуальные машины между ними или поддерживать распределенную архитектуру кластеров.
Чтобы понять концепцию NSX можно провести аналогию с серверной виртуализацией, отмапив инфраструктуру VMware vSphere на инфраструктуру "гипервизора" NSX:
Такая архитектура, конечно же, требует интеграции с агентами в физическом оборудовании, которые уже есть в сетевых устройствах Arista, Brocade, Cumulus, Dell, HP и Juniper.
Сама же платформа VMware NSX включает в себя следующие компоненты:
Controller Cluster - это система, состоящая из виртуальных или физических машин (как минимум 3), предназначенная для развертывания виртуальных сетей во всем датацентре. Эти машины работают в кластере высокой доступности и готовы принимать управляющие команды от различных средств через API, например, VMware vCloud или OpenStack. Кластер осуществляет управление объектами vSwitches и Gateways, которые реализуют функции виртуальных сетей. Он определяет топологию сети, анализирует поток трафика и принимает решения о конфигурации сетевых компонентов.
Hypervisor vSwitches (NSX Virtual Switches) - это виртуальные коммутаторы уровня ядра ESXi с программируемым стеком L2-L4 и конфигурационной базой. Они отвечают за работу с трафиком виртуальных машин, обеспечение туннелей VXLAN и получают команды от Controller Cluster.
Gateways - это компоненты, предназначенные для сопряжения виртуальных и физических сетей. Они предоставляют сервисы IP routing, MPLS, NAT, Firewall, VPN, Load Balancing и многое другое.
Ecosystem partners - партнеры могут интегрировать собственные виртуальные модули (Virtual Appliances) в инфраструктуру NSX на уровнях L4-L7. Подробнее об этом написано здесь.
NSX Manager - это централизованное средство управления виртуальными сетями датацентра (с веб-консолью), которое взаимодействует с Controller Cluster.
Посмотрим на высокоуровневую архитектуру решения:
Как мы видим, NSX оперирует собственными виртуальными сетями, которые инкапсулируют в себе физические сети средствами протоколов STT, VXLAN и GRE (как это делается мы уже писали вот тут). А компонент NSX Gateway выполняет функции моста для коммутации на уровне L2 и маршрутизации на уровне L3.
В качестве серверных гипервизоров в инфраструктуре NSX могут быть использованы решения VMware vSphere, KVM или Xen.
Надо отметить, что есть два варианта развертывания решения:
Окружение, состоящее только из хостов vSphere: в этом случае NSX опирается на инфраструктуру vSphere Distributed Switch (VDS) при взаимодействии с компонентами решения. А компонент NSX Gateway опирается на решение NSX Edge, которое было выделено из подпродукта vCNS Edge (бывший vShield Edge).
Гибридное окружение с несколькими гипервизорами: тут NSX уже использует Open vSwitch для KVM и Xen, а также собственный виртуальный коммутатор NSX vSwitch, работающий на уровне ядра ESXi. С точки зрения шлюза тут уже NSX может использовать различные физические модули.
Вот так выглядит детальная архитектура решения VMware NSX с учетом развертывания в среде только с VMware vSphere (обратите внимание, что NSX может работать только с одним сервером vCenter - это ограничение архитектуры):
Тут видно, что на уровне гипервизора работают 4 компонента, так или иначе используемых NSX:
Distributed Firewall - распределенный сетевой экран, который мы упоминали вот тут.
А вот так выглядит решение NSX в гибридной среде с несколькими гипервизорами:
С точки зрения логических функций NSX выполняет следующее:
Logical Switching - NSX использует комбинацию Stateless Transport Tunneling (STT), Generic Routing Encapsulation (GRE) и VXLAN для гибридных окружений или только VXLAN для окружений vSphere, чтобы предоставлять коммутацию уровня L2 вне зависимости от нижележащей топологии сети. Теперь все происходит на уровне эмулируемой структуры виртуальных сетей, не затрагивающей IP-адреса и не привязанной к физическому расположению, что значит, что виртуальную машину можно перемещать между датацентрами без изменения конфигурации сетей.
Поддержка аппаратных туннелей - VXLAN Tunnel Endpoints (VTEPs), которые позволяют поддерживать технологию виртуальных сетей на аппаратном уровне и не создавать задержек в сети.
Logical Routing - теперь L3-маршрутизация возможна на логическом уровне, вне зависимости от нижележащего оборудования и за счет наличия distributed routing (DR) module в VMware ESXi с поддержкой протоколов динамической маршрутизации BGP и OSPF.
Logical Firewalling - эти возможности пришли из продукта vCNS App (vShield App), они позволяют обеспечить комплексную защиту датацентра средствами модулей распределенного сетевого экрана (distributed firewall, DFW).
Logical Load Balancing and VPN - эти функции были также взяты из vCNS и поддерживаются только для окружений vSphere. В этом случае компонент NSX Edge осуществляет балансировку соединений на уровне L7 с поддержкой различных алгоритмов, а также позволяет организовать надежный VPN-туннель к инфраструктуре на базе IPsec и SSL.
Более подробно о решении VMware NSX можно узнать на этой странице.
Как вы уже знаете, не так давно была выпущена обновленная версия платформы виртуализации VMware vSphere 5.5, которая получила немало новых возможностей. Вместе с тем была также выпущена бесплатная версия VMware vSphere Hypervisor 5.5 (free ESXi 5.5).
Самым главным улучшением VMware ESXi 5.5, бесспорно, стало отсутствие ограничений на физическую память хост-сервера. Если раньше мы могли использовать бесплатный ESXi только на серверах, где установлено до 32 ГБ RAM:
то теперь VMware ESXi 5.5 не имеет абсолютно никаких ограничений сверху по памяти физического сервера.
Это хорошая новость, но есть и немного плохая. Если ограничения сверху теперь отсутствуют, то ограничения снизу всегда будут - это системные требования. В версии ESXi 5.0 для запуска хоста требовалось минимум 2 ГБ оперативной памяти (если вы ставили его в кластер, то уже требовалось 3 ГБ, так как с двумя гигами хост вылетал в PSOD). В версии же ESXi 5.5 теперь официально требуют 4 ГБ RAM. Это значение важно, конечно же, не для физических хостов ESXi 5.5, а для виртуальных - которые используются для тестирования возможностей инфраструктуры виртуализации.
Отметим, что ограничение на 8 vCPU на одну виртуальную машину в бесплатном ESXi 5.5 осталось.
Ну а с точки зрения самого бесплатного гипервизора VMware ESXi 5.5 появились следующие новые возможности:
Обновленная версия виртуального аппаратного обеспечения - Virtual Machine Hardware Version 10.
Поддержка новых архитектур CPU.
Совместимость ВМ в VMware ESXi 5.5 - теперь обеспечивается обратная совместимость ВМ с поддержкой различных возможностей, таких как LSI SAS для Oracle Solaris 11 OS и advanced host controller interface (AHCI).
Максимальное число vCPU на хост - 4096 (было 2048).
NUMA-узлов на хост - 16 (было 8).
Логических CPU на хост - 320 (было 160).
Поддержка дисков VMDK до 62 ТБ.
Поддержка адаптеров 16 GB Fibre Channel.
Поддержка сетевых адаптеров до 40 GBps.
До 64 ТБ хранилищ на один хост ESXi.
Один SATA-контроллер поддерживает виртуальный диск и CD-ROM на одном контроллере.
Поддержка до 30 устройств на контроллер, всего 4 контроллера - итого 120 устройств.
Ограничение на non-writable API все еще осталось, поэтому непонятно, как работают такие решения, как бесплатный Unitrends Enterprise Backup (UEB) - заявлено, что он может бэкапить виртуальные машины бесплатного ESXi.
Продолжаем знакомить вас с анонсами VMworld 2013, среди которых было немалоинтересного. Как вы помните, у компании VMware в основном продуктовом портфеле есть решение VMware Site Recovery Manager, предназначенное для построения катастрофоустойчивой архитектуры на базе основной и резервной площадок. О предыдущей версии VMware SRM 5.1 мы уже писали вот тут. Ну а сегодня расскажем про VMware Site Recovery Manager 5.5.
Но сначала для тех, кто хочет знать, как об этом рассказывали на VMworld:
Напомним, что в SRM можно использовать репликацию на уровне дисковых массивов (array-based), которая работает быстро, надежно (до RPO=0) и синхронно (или асинхронно), но требует вложений в инфраструктуру, а также host-based репликацию по сети передачи данных, которая работает менее эффективно (RPO - от 15 минут до 24-х часов), зато использует существующую инфраструктуру Ethernet. О некоторых улучшениях host-based репликации в VMware vSphere 5.5 мы уже упоминали в этой статье.
Итак, что нового появилось в VMware SRM 5.5:
Возможность протестировать процедуру аварийного восстановления с двух сторон, без нарушения работы производственного окружения.
Поддержка виртуальных машин с дисками более 2 ТБ.
Поддержка Windows Server 2012 для установки компонентов SRM.
Новые настройки для поддержки режима vSphere Replicaiton.
При перемещении машин в рамках одной consistency group полностью поддерживаются техники Storage DRS и Storage vMotion.
Защита виртуальных машин, хранилища которых находятся на бэкэнде Virtual SAN (vSAN). Естественно, это реализовано на базе vSphere Replication.
Поддержка техники multiple point-in-time (MPIT) - нескольких точек для восстановления целевой реплицируемой машины. Это защищает сервисы от логических повреждений данных, изменения в которых реплицируются на резервную площадку.
SRM 5.5 больше не поддерживает базу данных IBM DB2.
Надо отметить, что для управления инфраструктурой SRM по-прежнему требуется "толстый" клиент vSphere Client (напомним, что его не убрали из vSphere 5.5, хотя и обещали - похоже именно из-за сопутствующих продуктов), а про поддержку vSphere Web Client пока ничего не говорят.
Интересной новой возможностью, о которой шла речь на VMworld, стал сценарий создания резервной инфраструктуры SRM в одном из поддерживаемых публичных облаков (он может быть использован как общий Recovery-сайт для нескольких филиалов компании):
Лицензирование продукта осталось прежним - либо за защищаемые виртуальные машины (если покупаем просто SRM), либо по процессорам хостов VMware ESXi (если покупаем в составе vCloud Suite).
О доступности для загрузки VMware Site Recovery Manager 5.5 будет объявлено несколько позднее.
Ну и помните (на всякий случай) предупреждение VMware:
Using SRM and vSphere Replication to replicate and recover virtual machines on VMware Virtual SAN datastores can results in incomplete replications when the virtual machines are performing heavy I/O. ESXi Server can stop unexpectedly.
Кстати, в будущем нам обещают, что VMware SRM будет доступен в виде виртуального модуля (Virtual Appliance).
Таги: VMware, SRM, Update, vSphere, Replication, DR
Как многие из вас знают, сейчас проходит конференция VMworld 2013, проводимая компанией VMware, на которой было сделано немало интересных анонсов в продуктовой линейке ведущего вендора решений для виртуализации.
Приведем здесь список того, что было анонсировано и где можно почерпнуть дополнительной информации:
Обновилась платформа виртуализации - VMware vSphere 5.5. О новых возможностях vSphere 5.5 мы написали тут. Обратим внимание, что цены и издания продукта не изменились.
Изменилась комплектация и стоимость некоторых продуктов VMware. Об этом мы писали вот тут.
Обновился пакет VMware vCloud Suite 5.5, включающий в себя основные решения для организации частного облака на основе VMware vSphere 5.5. Мы писали об этом тут. А о новых особенностях версии 5.5 можно прочитать тут. В ближайшее время мы расскажем об этом подробнее.
Обновилось решение для автоматизации частного облака vCloud Director 5.5, подробнее об этом можно почитать тут. Скоро и здесь об этом будет.
Обновились службы единого входа Single Sign On 2.0. Подробности приведены здесь.
Был существенно улучшен механизм vSphere Replication 5.5. Некоторые детали приведены у нас тут. На английском можно почитать здесь.
Обновилось решение для создания катастрофоустойчивой инфраструктуры VMware Site Recovery Manager 5.5. Скоро мы об этом здесь также напишем. Пока почитайте о нем вот тут.
Обновилось решение
vSphere Data Protection Advanced, которое входит в состав VMware vSphere для изданий, начиная с vSphere Essentials Plus (напомним, что выпущено оно было еще в начале года). Почитать можно тут.
Была анонсирована доступность средства vCloud Planner 1.0 (он же бывший VMware Infrastructure Planner / VIP), предназначенного для финансовой оценки планируемой виртуальной инфраструктуры на базе дополнительных решений в рамках концепции Software Defined Datacenter на основе VMware vCloud Suite (то есть, что улучшится с точки зрения владения инфраструктурой, если закупить и развернуть последний). В качестве отправной точки для расчетов используется уже существующая инфраструктура на основе VMware vSphere. Подробнее об этом средстве можно узнать тут.
Было анонсировано средство, предназначенное для виртуализации сетей в рамках концепции Software-defined networking (SDN) - VMware NSX, о котором мы писали вот тут. Немного дополнительной информации находится здесь. Скоро мы также опишем его несколько подробнее.
Анонсировали обновленную версию решения для комплексного мониторинга и защиты сетей
vCloud Networking and Security 5.5 в составе vCloud Suite 5.5. Подробнее об этом тут.
Выпустили новую минорную версию решения для высокой доступности сервисов vCenter - vCenter Server Heartbeat 6.6.
Ну и (если кто не заметил) обновился сайт VMware. Теперь все так модно делать - в стиле Ленты.ру.
Скоро о многом из этого мы расскажем достаточно подробно. Заходите чаще!
Не так давно мы уже писали о планируемых новых возможностях VMware vSphere 5.5, однако большинство новых функций были описаны в общих чертах, кроме того, до последнего момента так и не было окончательно известно, что же еще нового появится в vSphere 5.5. На проходящей сейчас конференции VMworld 2013 компания VMware наконец-то объявила о выходе обновленной платформы VMware vSphere 5.5, которая стала еще более мощным средством для построения виртуальных инфраструктур.
Не так давно мы писали про утилиту VMware View Planner 2.0, которая позволяет смоделировать и организовать нагрузочное тестирование инфраструктуры виртуальных ПК на платформе VMware Horizon View.
Тестирование производительности для реальных моделей нагрузок на основе популярных приложений.
Уникальная технология для измерения производительности виртуального ПК для адекватного замера пользовательских метрик.
Методология, позволяющая повторять тесты и масштабировать их.
Метрики, позволяющие определить сильные стороны инфраструктуры - глубину размещения виртуальных ПК, производительность и экономическую эффективность.
Поддержка последних версий VMware vSphere и VMware Horizon View.
Улучшенные отчеты по статистикам.
Автоматически генерируемые отчеты в PDF.
Суммарный отчет View Planner 3.0 предоставляется в виде метрики VDImark. Эта метрика показывает, сколько пользователей может использовать виртуальные ПК VMware View без превышения заданных пороговых значений задержек (response time) для приложений.
Операции, проверяемые View Planner 3.0, разделены на три группы:
(1) Group A - базовые интерактивные операции (пороговое значение - 1 секунда).
(2) Group B - операции ввода-вывода (I/O operations).
(3) Group C - операции в фоновом режиме (пороговое значение - 6 секунд)
При тестировании VDI-инфраструктуры с помощью View Planner в этой статье использовалась следующая базовая конфигурация оборудования (замерялись значения для 3,5 и 6 хостов ESXi при такой нагрузке - 285 ВМ (3 хоста), 480 ВМ (5 хостов) и 560 ВМ (6 хостов)).
Результаты получились весьма ровными и попадающими в нужные диапазоны:
Как минимум 95% ВМ попадали в эти пороговые значения, что является весьма неплохим результатом для такого количества машин, размещенного на протестированном оборудовании.
Несколько детальнее по самим тестам операций группы А:
По тестам операций группы Б:
Результаты по IOPS:
Более подробно о VMware View Planner 3.0 можно почитать по этой ссылке. Скачать его можно по этой.
Как известно, инфраструктура виртуальных ПК всегда обладала такой особенностью, что приложения, требовательные к производительности 3D-графики, как правило не переносили в VDI-среду. Сначала эту парадигму начала изменять компания Citrix, которая продвигала концепцию виртуализации требовательных к графике нагрузок, опираясь на разработки компании NVIDIA VGX, о которых мы уже писали вот тут, тут и тут. Естественно, NVIDIA стала сотрудничать и с компанией VMware - лидера на рынке если и не VDI-решений, то уж точно платформ виртуализации.
Выпустив VMware Horizon View 5.2, компания VMware сделала серьезный шаг в направлении улучшения производительности 3D-графики в виртуальных десктопах. Теперь о возможностях отображения графики в виртуальных ПК можно говорить в разрезе трех техник:
Soft 3D - рендеринг 3D-картинки вообще без использования адаптера на основе программных техник с использованием памяти сервера.
vDGA - выделение графического адаптера (GPU) отдельной виртуальной машине.
vSGA - использование общего графического адаптера несколькими виртуальными машинами.
Понятно, что режимы vDGA и vSGA должны поддерживаться со стороны производителя аппаратного обеспечения, что и предоставляет NVIDIA в своих графических адаптерах (информация актуальна для релиза VMware View 5.2):
Краткое сравнение обеих техник:
Рассмотрим эти режимы немного подробнее.
Soft 3D - графическая карта не нужна
В этом режиме сервер может работать без графического адаптера, при этом рендеринг картинки происходит программными средствами с использованием выделенной области оперативной памяти. Так сейчас работает большинство серверов и десктопов, которым не требуется особая производительность графики. При этом поддерживается программная обработка для приложений, работающих с DirectX 9 и OpenGL 2.1.
В этом случае один GPU видеокарты выделяется только одной виртуальной машине, а его использование происходит посредством установленного в ней драйвера NVIDIA:
Надо отметить, что поскольку в этом режиме ВМ завязана на физическое устройство, то для нее не поддерживаются функции динамических сервисов, такие как HA, vMotion и DRS. Однако это лучший способ гарантировать виртуальной машине производительность.
vSGA (Virtual Shared Graphics Adapter) - общий GPU для нескольких виртуальных машин
В этом режиме один GPU через драйвер NVIDIA рендерит картинку сразу для нескольких виртуальных машин. Для этого режима используется специальный драйвер на уровне ядра VMware ESXi, который обрабатывает запросы нескольких виртуальных машин к одному адаптеру. Понятное, дело этот способ не гарантирует производительности, однако подходит для большинства инсталляций, в случаях, когда ВМ не требуется высокой и гарантированной производительности в области 3D-графики.
В консоли VMware View настройки графических режимов производятся на уровне пула виртуальных ПК. Видеопамять, выделяемая под ВМ, использует либо ресурсы памяти хост-сервера (это важно учитывать при сайзинге памяти для виртуальных машин на хосте), либо также его аппаратные графические ресурсы.
RSS
